The process of fabricating integrated circuits typically involves a functional design step, followed by a physical design step. During the functional design step, a design concept is described using a hardware description language and is then converted into a netlist, which specifies the electronic components and the connections between the components. The physical design step specifies the placement of the electrical components or elements on the chip and routing of the connections between the electrical components and thereby implementing the netlist. The physical design process generates the physical design data, which are synonymously called layout data, target layout, or an IC mask layout.
The IC mask layout represents an IC in terms of planar geometric shapes, and in other words defines a set of binary patterns or objects, which are also called features or geometric features. Usually the objects are represented as a polygon or collection of polygons in the layout data in order to facilitate the specification of the objects. Each object can be a part of an electronic component, such as a gate of a transistor or a connection between components. Each polygon object has vertices and edges joining the vertices. Each vertex is usually defined by its coordinates in a Cartesian x-y coordinate system.
These planar geometric shapes correspond to the shapes actually drawn on photo masks used in semiconductor device fabrication. The IC layout may then be created by automatic electronic development automation (EDA) tools. By way of example, the EDA tools may include place and route tools, and schematically driven layout tools. The IC layout can also be created and edited manually by an IC designer.
The IC layout results in the representation of the IC in various IC mask layout data formats. By way of example, the IC mask layout data formats can be stored in a GDS database format, a MEBES database format, or an OASIS database format. These IC mask layout data formats involve a binary format for the representation of planar geometric shapes, text labels, and other information in a flat or hierarchical manner.
The layout data needs to be imported to a target system, where a customer can work on the data. FIG. 1 is a prior-art block diagram of importing layout data file from a host system to a target library in a target system according to presently available methods. As depicted in FIG. 1, the layout data files are stored in a layout database 102 in a GDS database format. The semiconductor design flows uses the mask layout data stored in the layout database 102 to exchange physical design information. The mask layout data is then transferred to a target disk location 104 in the target system, to reconstruct the design data as it is processed across different design tools 106 before finally handing over to foundries for fabrication.
The continuing advances in semiconductor fabrication technology, and the increasing demand for complex functionality in modern semiconductor chips has led to generation of an exponentially larger mask layout data, and therefore a large amount of data has to be transmitted to the target disk location in the target system. The typical mask layouts are taken through several exchanges across the design tools 106 for design transformations, such as design rule check (DRC) removal, LVL verification, chip-level integration, chip-finishing editing, and final verification at foundry. At each stage, a large-sized hierarchical layout needs to be imported into a corresponding design tool 106 and edited. This involves the translation of the mask layout data into the target library 104 supporting the hierarchical design.
The target system hierarchical databases like Open Access store different elements of hierarchy in individual directories and files. Hence, importing a typical mask layout for a hierarchical design needs the creation of directories and files in the order of millions. While the core translation process of converting layout information to target database objects is host system CPU intensive, creating the target disk location representation of the hierarchical design is highly I/O intensive. The network disk setups makes I/O slower depending on the network latency. Since multiple iterations of translation are required in the full design flow from the beginning of physical design to chip fabrication, the mask layout import ends up consuming a sizeable amount of the IC designer time.
As depicted in FIG. 2, each step involves a portion of host system CPU operation which makes a system call for the target disk access and logic execution. This is the reason the host system CPU and the target disk operations gets interleaved. In a normal scenario, the target disk is shared between several processes and users that make this flow very time consuming. This target disk sharing is time consuming because the target disk is assigned to other users/processes when the CPU operations are being executed, and is assigned back to the import process when the CPU needs to perform the disk access. The target disk sharing also increases the disk head movements. Therefore, the import of one cell view from the mask layout data has to go through these interleaved CPU and the target disk operations which tends to consume significant time.
Therefore, there is a need for methods and systems that addresses the above mentioned drawbacks of the conventional techniques employed for mask layout data import, and is thereby able to reduce translation time for large hierarchical layouts that leads to higher productivity.